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(54) System for signatureless transmission and reception of data packets between computer 
networks 



(57) A system for automatically encrypting and de- 
crypting data packet sent from a source host to a desti- 
nation host across a public internetwork. A tunnelling 
bridge is positioned at each network, and intercepts all 
packets transmitted to or from its associated network. 
The tunnelling bridge includes tables indicated pairs of 
hosts or pairs of networks between which packets should 
be encrypted. When a packet is transmitted from a first 
host, the tunnelling bridge of that host's network inter- 
cepts the packet, and determines from its header infor- 
mation whether packets from that host that are directed 
to the specified destination host should be encrypted; or. 
alternatively, whether packets from the source host's net- 
work that are directed to the destination host's network 
should be encrypted. If so, the packet is encrypted, and 
transmitted to the destination network along with an en- 
capsulation header indicating source and destination in- 
formation: either source and destination host addresses, 
or the broadcast addresses of the source and destination 
networks (in the latter case, concealing by encryption the 
hosts' respective addresses). An identifier of the source 



networks tunnelling bridge may also be included in the 
encapsulation header. At the destination network, the as- 
sociated tunnelling bridge intercepts the packet, inspects 
the encapsulation header, from an internal table deter- 
mines whether the packet was encrypted, and from ei- 
ther the source (host or network) address or the tunnel- 
ling bridge identifier determines whether and how the 
packet was encrypted- If the packet was encrypted, it is 
now decrypted using a key stored in the destination tun- 
nelling bridge's memory, and is sent on to the destination 
host. The tunnelling bridge identifier is used particularly 
in an embodiment where a given network has more than 
one tunnelling bridge, and hence multiple possible en- 
cryption/decryption schemes and keys. In an alternative 
embodiment, the automatic encryption and decryption 
may be carried out by the source and destination hosts 
themselves, without the use of additional tunnelling 
bridges, in which case the encapsulation header in- 
cludes the source and destination host addresses. 
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Description 

The present invention relates to the field of secure transmission of data packets, and in particular to a new system 
for automatically encrypting and decrypting data packets between sites on the Internet or other networks of computer 
5 networks. 

It is becoming Increasingly useful for businesses to transmit sensitive information via networks such as the Internet 
from one site to another, and concomitantly more urgent that such information be secured from uninvited eyes as it 
traverses the tntemetwork. At present, unsecured data is replicated at many sites in the process of being transmitted to 
a destination site, and trade secret or other private information, unless secured, is thereby made available to the public. 

10 It is possible for a user at the sending host to encrypt the data to be sent, and to inform the user who is to receive 

the data of the encryption mechanism used, along with the key necessary to decrypt. However, this requires communi- 
cation and coordinated effort on the parts of both the sending and receiving users, and often the users will not take the 
requisite trouble and the packets will go unencrypted. 

Even when these packets are encrypted, the very fact of their being transmitted from user A to user B may be 

15 sensitive, and a system is needed that will also make this information private. 

Figure 1 illustrates a network of computer networks, including networks N1 , N2 and N3 interconnected via a public 
network 10 (such as the Internet). When network N1 is designed in conventional fashion, it includes several to many 
computers (hosts), such as host A and additional hosts 20 and 30. Likewise, network N2 includes host B and additional 
hosts 40 and 50, while network N3 includes hosts 60-90. There may be many hosts on each network, and many more 

20 Individual networks than shown here. 

When a user at host A wishes to send a file, email or the like to host B. the file is split Into packets, each of which 
typically has a structure such as packet 400 shown In Figure 7, including data 410 and a header 420. For sending over 
the Internet, the header 420 will be an internet protocol (IP) header containing the address of the recipient (destination) 
host B. In conventional fashion, each data packet Is routed via the Internetwork 10 to the receiving network N2. and 

25 ultimately to the receiving host B. 

As Indicated above, even if the user at host A encrypts the file or data packets before sending, and user B is equipped 
with the necessary key to decrypt them, the Identities of the sending and receiving hosts are easily discernible from the 
Internet Protocol (IP) addresses in the headers of the packets. Current internetworks do not provide an architecture or 
method for keeping this information private. More basically they do not even provide a system for automatic encryption 

30 and decryption of data packets sent from one host to another. 

The system of the invention includes a tunnelling bridge positioned at the Interface between a private network and 
a public network (or Internetwork) for each of a number of such private networks. Each tunnelling bridge is a stand-alone 
computer with a processor and a memory, and In each tunnelling bridge's memory is a hosts table identifying which 
hosts should have their data packets (sent or received) encrypted. Atternatlveiy, a networks table could be used, indi- 

35 eating whether data packets to and from particular networks should be encrypted; or other predetermined criteria may 
be stored that indicate whether particular data packets should be encrypted. 

The tunnelling bridge for a given private network (or subnetwork of a private network) intercepts all packets sent 
outside the network, and automatically determines from the tables whether each such packet should be encrypted. If 
so, then the tunnelling bridge encrypts the packet using an encryption method and key appropriate for the destination 

40 host, adds an encapsulation header with source and destination address Information (either host address or IP broadcast 
address for the network) and sends the packet out onto the internetwork. 

At the destination host, another tunnelling bridge Intercepts all incoming data packets. Inspects the source and 
destination address Information, and determines from Its local hosts (or networks) table whether the packet should be 
decrypted, and If so, by what method and using what key The packet is decrypted, if. necessary, and sent on to the 

4S destination host. 

In this way. all messages that are predetermined to require encryption, e.g. all messages from a given host A to 
another host B, are automatically encrypted, without any separate action on the part of the user. In this way, no one on 
the public internetwork can determine the contents of the packets. If the encapsulation header utilizes the network IP 
source and destination addresses, with the source and destination host addresses encrypted, then the host identities 
50 are also concealed, and an intervening observer can discern only the networks' identities. 

The encapsulation header may include a field with an Identifier of the source tunneling bridge. This is particularly 
useful If more than one tunnelling bridge Is to be used for a given network (each tunnelling bridge having different 
encryption requirements and information), and in this case the receiving tunnelling bridge decrypts the data packets 
according to locally stored information indicating the encryption type and decryption key for all packets coming from the 
55 source tunnelling bridge. 

By way of example only, specific embodiments of the present invention will now be described, with reference to the 
accompanying drawings, In which: - 

Figure 1 Is a diagram of a network of computer networks in conjunction with which the system of the present invention 
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may be used. 

Figure 2 is a block diagram of a host computer A on computer network N1 shown in Figure 1 
Figure 3 is a diagram of a network of computer networks incorporating tunnelling bridges according to the present 
invention. 

5 Figure 4 is a block diagram of several tunnelling bridges of the present invention in a network of computer networks 

N1-N3 as shown in Figure 3. 

Figure 5 is a diagram of another configuration of networks incorporating tunnelling bridges according to the present 
invention. 

Figure 6 is a flow chart illustrating the method of signatureless tunnelling of the present invention. 
?o Figure 7 illustrates a'conventional data structure for a data packet. 

Figures 8-11 illustrate modified data structures for use In different embodiments of the system of the invention. 
Figure 1 2 is a block diagram of a network of computer networks including two tunnelling bridges of the invention on 
a single computer network. . / : , . 

The system of the present invention is designed to be implemented in existing computer networks, and in the pre- 
ferred embodiment uses the addition of a tunnelling bridge at junctions between local computer networks and public or 
larger-scale networks such as the Internet. The mechanisms for carrying out the method of the invention are implemented 
by computers acting as these tunnelling bridges, incorporating program instructions stored in memories of the tunnelling 
bridges and appropriate (standard) network connections and communications protocols. 

Figure 3 shows a network 1 00 of networks N1 , N2 and N3 according to the invention, where each network includes 
20 a tunneling bridge ~ TBI . TB2 and TB3. respectively ~ which intercepts all data packets from or to the respective 

"^J^.^^®: ■J^A'^^y other respects be identical to networks N 1 -N3 in conventionaldesigns. In the following 

description, any references to networks N1 -N3 or hosts A and B should be taken as referring to the configuration shown 
in Figure 3, unless specified otherwise. - 

in this system, there are several modes of operation, numbered and discussed below as modes 1 , 2. 2A, 3 and 3A. 
Mode 1 uses the configuration of Figure 1, while the other modes all use the configuration of Figure .3. The features of 
the tunnelling bridges TB1 and TB2 (including their program instructions, actions taken, etc. ) in modes 2-3A are. in mode 
1 , features of, respectively, hosts A and B. 

Each of the tunnelling bridges TB1-TB3 Is preferably implemented in a separate, conventional computer having a 
processor and a memory, as shown in Figure 4. The memory may be some combination of random-access-memory 
(RAM), read-only-memory (ROM), and other storage media, such as disk drives, CD-ROMs, etc. The program instruc- 
tions for each of the bridges TB1-TB3 are stored in their respective memories, and are executed by their respective 
microprocessors. The method of the present invention Is carried out by a combination of steps executed as necessary 
by each of the processors of the sending host A, the tunnelling bridges TBI and TB2. and the receiving host B. 

Encryption of data is an important step in the overall method of the invention, but the particular encryption mechanism 
3S used is not critical. It is preferable to use a flexible, powerful encryption approach such as the DIffie-Hellman method 
(see W. Diffieand M. Hellman, "New Directions in Cryptography", IEEE Transactions of Information Theory, November 
1976). (The use of encryption in connection with IP data transfers is discussed in some detail in applicant's copending 
patent application, "Method and Apparatus for Key-Management Scheme for Use With Internet Protocols at Site Fire- 
walls" by A. Aziz, Ser. No. 08/258,344 filed June 10, 1994; which application Is incorporated herein by reference.) How- 
ever any encryption scheme that provides for eneryption by a first machine, which sends the data packets, and decryp- 
tion by a receiving machine, will be appropriate. 

Figure 6 illustrates the method of the invention, and commences with the generation of data packets at the sending 
host A. The user at host A enters conventional commands for transmitting a file or the like frpm host A to host B. and 
the host computer A carries out the standard procedures for breaking the file down into data packets as in Figure 7. 
each including both the data 410 and a header 400. In the case of transmissions over the Internet, this will be the IP 
header. Though the current discussion will be directed in large part to IP-specific implementations. It should be under- 
stood that any network protocol may be used in conjunction with the present Invention. 

At box 200. the user at host A (see Figures 3 and 6) enters the conventional command for sending the file, email, 
or,the like to a recipient, and host A generates data packets for sending over the Internet in the normal fashion. Each 
data packet initially has a structure like that of data packet 400 shown in Figure 7. including a data field 41 0 and a header 
field 420. The header 420 includes the destination address, in this example the IP address of host B. 

The data packets are transmitted by host A at box 210, again in conventional fashion. However, at box 220, each 
packet is intercepted by the tunnelling, bridge TB 1 (see Figures 3 and 4). when any of modes 2, 2A, 3or 3A is used 
(see discussion below). When mode 1 (described below) is'used. steps 220 and 280 are omitted, since this mode does 
not use tunnelling bridges; instead, the actions taken by the tunnelling bridges in modes 2-3A are all accomplished by 
the source and destination hosts themselves in mode 1. Thus, in the following discussion, wherever TBI or TB2 Is 
mentioned, it should be understood that iri the case of mode 1, the same feature will be present in host A or host B 
respectively. 
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Stored in the memory of TB1 (or host A, for mode 1 ) is a look-up table (not separately shown) of the addresses of 
hosts, both on the local network N1 and on remote networks such as N2 and N3. and an indication for each network 
whether data packets from or to that host should be encrypted. For instance., in this case the hosts table of TB1 indicates 
that any messages sent from host A to host B should be encrypted. Thus, bridge TB 1 (or host A) looks up hosts A and 
5 B in its tables, and determines that the data packets to be transmitted must first be encrypted, as indicated at boxes 
230 and 240 of Figure 6. 

Alternatively, the table could stored the network identifiers (e.g. broadcast addresses) of networks N1 and N2. 
indicating that anything sent from network N1 to network N2 is to be encrypted. In this case, the table need not list each 
host in each network, which makes the table smaller and easier to maintain. 
10 If each host is listed, however, greater flexibility can be retained, since it may be that messages to or from particular 

hosts need or should not be encrypted. In an alternative embodiment, the look-up table lists the networks N1 and N2 
as networks to and from which packets should be encrypted, and also includes a hosts section of the table indicating 
exceptions to the normal encryption rule for these networks. Thus, if networks N1 and N2 are listed in the look-up table, 
then packets travelling from Nl to N2 should normally be encrypted; however, if there is an "exceptions" subtable indi- 
es eating that no packets from host A are to be encrypted, then the normal rule is superseded. The exceptions can. of 
course, go both ways: where the normal rule is that the packets for a given network pair should/should not be encrypted, 
and the exception is that for this given host (source or recipient) or host pair, the packet should not/should nonetheless 
be encrypted. In this embodiment, the small size and ease of maintenance of the networkXab\es is by and large retained, 
while the flexibility of the hosts table is achieved. 
20 If the data to be transmitted from host A to host B (or network Nl to network N2) should not be encrypted, then the 

method proceeds directly to step 270, and the packet in question is transmitted unencrypted to the destination, via the 
Internet (or other intervening network). 

In this example, the packets are encrypted at box 250. This is carried out by the tunnelling bridge TB1, according 
to whichever predetermined encryption scheme was selected, the primary requirement being that of ensuring that TB2 
25 is provided with the same encryption scheme so that it can decrypt the data packets. TB2 must also be provided in 
advance with the appropriate key or keys for decryption. 



The Encapsulation Header 
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At box 260, an encapsulation header is appended to the encrypted data packet. This header can take one of several 
alternative forms, according to the requirements of the user. Several modes of packet modification can be accommodated 
using the same basic data structure (but with differences in the information that is appended in the encapsulation header), 
such as the following: 



35 



Mode 



Appended information 



40 



45 



50 



55 



1 

2 



2A 
3 



3A 



Encryption key management information (itself unencrypted) 

New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 
Encryption key management information (in encrypted form) 
Tunnelling bridge identifier for sender (unencrypted) 

New IP header including broadcast addresses of source and destination networks (unencrypted) 
(Same as mode 2. but without the tunnelling bridge identifier.) 
Encryption key management information (encrypted) * 
Optional: tunnelling bridge identifier for sender (unencrypted) 

New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 
(Same as mode 3, but without the tunnelling bridge identifier.) " 



Data structures for modes 1. 2 and 3 are depicted in Figures 8. 9 and 10, respectively, wherein like reference 
numerals indicate similar features, as described below. The data structure for mode 2A is illustrated in Figure 11, and 
mode 3A may use the data structure of Figure 8. 

The data structure 402 for mode 1 is represented in Figure 8. The original data 410 and original header 420 are 
now encrypted, indicated as (410) and (420). Encryption key management information 440 is appended (in encrypted 
form) as part of the new encapsulation header 430, along with a new IP header 450, including the addresses of the 
source and destination hosts. The information 430 includes indicates which encryption scheme was used. 

Key management information can include a variety of data, depending upon the key management and encryption 
schemes used. For instance, it would be appropriate to use applicant's Simple Key-Management for Internet Protocols 
(SKIP), which is described in detail in the attached Appendix A. 



5 



EP 0 702 477 A2 



In Figures 7-11, the fields with reference nunnerals in parentheses are encrypted, and the other fields are unen- 
crypted. Thus, in Figure 8, the original data field 410 and address field 420 are encrypted, while the new encapsulation 
header 430: including the key management information 440 and the IP header 450. is not encrypted. 

In this embodiment, the tunnelling bridges TBI and TB2 might not be used at alL but rather the hosts A and B could 
include all.the instructions, tables, etc. necessary to encrypt, decrypt, and determine which packets are to be encrypted 
and using which encryption scheme. Mode 1 allows any intervening observer to identify the source and destination 
hosts, and thus does not provide the highest level of security. It does, however provide efficient and automatic encryption 
and decryption for data packets between hosts A and B, without the need for additional computers to serve as TBI and 
TB2. 

Alternatively, in mode 1 field 440 could include the IP broadcast addresses of the source and destination networks 
(instead of that of the hosts themselves), and in addition may include a code in the encryption key management infor- 
mation indicating which encryption scheme was used. This information, would then be used by an intercepting computer 
(such as a tunnelling bridge) on the destination.network. which decrypts the data packet and sends it on to the destination 
host. 

In mode 2, a data structure 404 is used, and includes a new encapsulation header 432. It Includes key encryption 
management information 440, which is appended to the original data packet 400, and both are encrypted, resulting In 
encrypted fields (410), (420) and (440) shown in Figure 9, A new IP header 470 Including the broadcast addresses of 
the source and destination networks (not the addresses of the hosts, as in field 450 in Figure 8) is appended. In addition, 
a tunnelling bridge identifier field 460 is appended as part of the encapsulation header .432. Here, fields 410, 420 and 
.,440 in this embodiment are all encrypted, while fields 460 and 470 are not. . 

The tunnelling bridge identifierjdentifies t^he soL/rcetunnejIirig brjdge, i.e. the tunnelling bridge at the network con- 
taining the host ff^om which the packet was sent. The recipient tunnelling bridge contains a tunnelling bridge look-up 
table, indicating for each known tunnelling bridge any necessary information for decryption, most notably the decryption 
method and key. 

An appropriate tunnelling bridge identifier might be a three-byte field, giving 2^4 or over 1 6 million unique tunnelling 
bridge identifiers. An arbitrarily large number of individual tunnelling bridges may each be given a unique identifier in 
this way, simply by making the field as large as necessary, and indeed the field may be of a user-selected arbitrarily 
variable size. If desired, a four-byte field can be used, which will accommodate over 4 billion tunnelling bridges, far 
exceeding present needs. 

Using mode 2, any observer along the circuit taken by a given data packet can discern only the tunnelling bridge 
identifier and the IP broadcast addresses for the source and destination networks. 

The IP broadcast address for the destination network will typically be something like "1 29. 1 44.0.0". which represents 
a particular network (in this case, "Eng.Sun.COM") but not any specific host. Thus, at intermediate points on the route 
of the packet, it can be discerned that a message. is traveling from, say, "Washington. edu" to "Eng.Sun.COM", and the 
identification number of the receiving tunnelling bridge can be determined, but that is the extent of it; the source and 
destination hosts, the key management information, and the contents of the data packet are all hidden. 

Mode 2A uses the data structure shown in Figure 1 1 , wherein the I P broadcast addresses for the source and recipient 
networks N1 and N2 are included in the encapsulation header field 470. but no tunnelling bridge identifier is used. This 
embodiment is particularly suitable for networks where there is only one tunnelling bridge for the entire network, or 
indeed for several networks, as illustrated in Figure 5. 

In Figure 5, a packet sent from host C to host D will first be sent from network N4 to network N5, and will then be 
intercepted by the tunnelling bridge TB4, which intercepts all messages entering or leaving these two networks. TB4 
will encrypt the packet or not, as indicated by its hosts look-up table. The packet traverses the public network and is 
routed to network N7, first being intercepted by tunnelling bridge TBS (which intercepts all messages entering or leaving 
networks N6-N8), and at that point being decrypted if necessary. 

In this embodiment or any embodiment where a packet is sent from a host on a network where a single tunnelling 
bridge is used for the entire source network or for multiple networks which include the source network, a tunnelling 
bridge identifier is not a necessary field in the encapsulation header. Since in this case only a given tunnelling bridge 
could have intercepted packets from a given host (e.g.. TB4 for host C in Figure 5), the identity of the source tunnelling 
bridge is unambiguous, and the destination tunnelling bridge TBS will include a table of hosts and/or networks cross-cor- 
related with TB4. Having determined that tunnelling bridge TB4 was the source tunnelling bridge, TBS then proceeds 
with the correct decryption. 

This approach has certain advantages, namely that it eliminates the need to "name" or number tunnelling bridges, 
and reduces the sizes of the data packets by eliminating a field. However a tunnelling bridge identifier field provides 
flexibility. For instance, in Figure 12, subnetworks Nil and N 12 are part of one larger network N 10, and each subnetwork 
Nil and N12 has its own assigned tunnelling bridge (TB7and TB8. respectively). Thus, subnetworks N11 and N12can 
be subjected to different types of encryption, automatically and that encryption can be altered at will for one subnetwork, 
without altering it for the other 
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A packet traveling from host F to host E in Figure 12 will include a source tunnelling bridge identifier {TB7) so that, 
when it reaches TB6 at network N9. it is identified correctly as having been encrypted by TB7 and not TBS. In this way, 
tunnelling bridge TB6 need maintain a table only the information pertaining to the tunnelling bridges, and does not need 
to maintain encryption/decryption specifics for the host or network level. (Note that TB6 still maintains information relating 
5 to whether to encrypt messages sent between host A and host B or network N1 and network N2. as the case may be, 
as discussed above.) 

The tunnelling bridge identifier may be used for a variety of other purposes relating to the source tunnelling bridge, 
such as statistics recording the number of packets received from that tunnelling bridge, their dates and times of trans- 
mission, sizes of packets, etc. 

10 An alternative to the use of hosts or networks tables in the memories of the source and destination tunnelling bridges 

(or source and destination hosts, as the case may be) would be any information identifying one or more predetermined 
criteria by which the source host or source tunnelling bridge determines whether to encrypt a given data packet Such 
criteria need not merely be source and destination information, but could include packet contents, time of transmission, 
subject header information, user id., presence of a key word (such as "encrypt") in the body of the packet, or other criteria. 

15 Mode 3 uses a data structure 406 as shown in Figure 10, which is identical to the data structure 402 except for the 

addition of field 460 containing the tunnelling bridge identifier, which is the same as the tunnelling bridge identifier dis- 
cussed above relative it mode 2. • - ' 

In this embodiment, as in mode 1, field 450 includes the original host IP addresses for the source and destination 
hosts (not the addresses of the networks, as in mode 2), and thus an observer of a mode 3 packet will be able to 

20 determine both the original sender of the data packet and the intended receiver. Either mode contains sufficient infor- 
mation to route packets through an internet to a recipient network's tunnelling bridge for decryption and ultimate delivery 
to the recipient host. 

Mode 3A may use the data structure shown in Figure 8, in conjunction with a network configuration such as those 
shown in Figures 3 or 12. The mechanisms and relative advantages are identical to those described above for mode 

25 2A, while the structure reveals the source and destination host addresses. 

Whichever encapsulation header is added at box 260 (see Figure 6), the packet is, at box 270. then transmitted to 
the destination network. At box 280, the destination network's tunnelling bridge (here. TB2 shown in Figure 3) intercepts 
the packet, which is accomplished by an instruction routine by which all packets are intercepted and inspected for en- 
capsulation header information indicating encryption. 

30 Thus, at box 290. the encapsulation header of the packet is read, and at box 300 it is determined whether the packet 

was encrypted. If a tunnelling bridge identifier forms a part of the encapsulated packet, then the method of encryption 
and decryption key are determined from the destination tunnelling bridge's (or destination host's, in the case of mode 
1) local tables. 

If no encryption was carried out on the packet, then it is sent on without further action to the correct host, as indicated 
35 at box 340. Otherwise, its encryption method is determined (box 320), and the packet is decrypted accordingly (box 
330). and then sent on as in box 340. ' 
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APPENDIX A 

Simple Key-Management For Internet Protocols (SKIP) Abstract 

There arc occasions where i : is advantageous :q puc authcndcicy and privacy fcamres a; ihe nei- 
wor< layer. Tnc vast majoniy of the privacy iid auLhenacation prococois in -Ji= Htsraraj^ deal 
^± session cnented key- rt anag=ircnt schemes. However. ni2Ay of the commonJy used ncc^vor>c 
layer protocols ^c.g IP ajid I.>ng) are session-Icss datagraiD . oriented protcxrols. We describe a key- 
mar.agement scheme that is paixicularly wcU s-^ted for use in conjiincrion with a scssion-lcss dat- 
agrar. protocol hkc TP or n>ig. W- also describe how this pmcocolcuy be used in die contexc of 
internee Eulucasong prococois. "niis key-rranageciTer.t scheme is desigrjed to be pLuPPed into the 
IP SecuritryProtocol (IPS?) <fr iPng. 

1.0 Oveiyiew 

Any kind of scalable and roljust key-mana^e^ienr scheire chat needs to scaie to Lhe numbe- of 
ncxes possaole in ifte Interne t needs 'x. be based oa an unccriying public-key ccra-ficate based ' 
-infr^micrure: This is thc-diiecdon djat. e.g. ui-e key-manipriiear^he^e for secui^ Intemet 
e-mail. Privacy tnhanced Mail or PEM (13, is taking. 

Tne cerrificates used by PEM are RSA pubUc key certincatcs. Use of RS A piibUc key cenificares 
ajso enaole the establishment of an amhendcated session key [2.3j. (By an RSA public key certif- 
:ca:e, w.nat is meant here is that the key being cenified is an RSA public key.) 

One way to obtain authendc.cy and privacy at a daugrara layer like IP is.co use RSA pub'ic key 
cemficates. an the lollowmi; descri?uon we use the terra [?, although IP is rrplacafaie by IPne =n 
^is contest). . / & • 

Tners are two ways RSA cejtf.cates can be used to provide authenqcicy and privacy tor a data- 
grain protocol. The first way is to use out-cf-baad esiabHshment of an authendcated session key, 
using one o: several session tey establishment protocols. TTiis session key can then be used 
to encrypt IP data trafnc. Su.rh a scheme has we disadvantage of establishing and ir.aintaining a 
pseudo session siatc underneath a session-less pratoccl. The IP scarce would need to fii^r com- 
.'Hunicate with uhc.IP desdna.-ion in order to acquLrc this session key. 

Also, as and when Lhe session key needs to fee changed. -J^e IP souitc and the IP dcsdnation n-ed 
to co^-mnunicate again in crd.:r to =ake this happen. Each such ccmmunicadon involves the use of 
a compuiaaor.ally expensive public -key cperarion. 

Tne second way an RSA csrificace can be used is to do in-ba-nd signalling of che packet encr>T>- 
aon key. where the packet er.crypuon key is encrypted in che recipient's public key. This is lhe 
way. <=.g. PEM and other putUc-key based secure e-=^ail systenis do caessagc encrypdcn 
A.tnough Lnis avoids the ses:;ip.n state estabHshraent requirement, and also does not renuL-e the 
.wo parses to communicate in order to set up a.nd change packet encrypdon.keys. this scherPe has 
!ne disadvantage of having c^y .the packet encrypdon key encrypted in the nscipienfspublic 
key tn every packet. ^ 
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Since an RS A encrypted key would minic^Iy need to be 64 bytes, and can be 128 bytes, this 
scheme incurs the overhead of 64- 12S bytes of i:eying tnformaricn in every packet, (As time 
progr:sscs» ±c RSA block v.izc would need :o be closer to 128 bytes simply for securiry reasons.) 
Also, as and when the packot encryption key changes, a pubhc key opcradon would need lo be 
penarmed in order to rrcovrr the new'packe: encryption key. Thus both the protocol and cocipu- 
tadonal overhead of such a scheme is high. 

Use of certified Diffic-HcllTaan (DH) [d] public-kcy5 can avoid the pscudo session state establish- 
men: and the communicatzcns requirement between the two ends in order to acquire and change 
packet encrypting keys. Fujthcrtnorc, this scheme docs not incur the overhead of carrying 
64- 128 by-ges of keying infcrmadon in every packet.- 

This kind of key-management scheme is ben^r suited lo protocols liice IP, because it doesn*: even 
require the remote side to bt up in order to establish and change packet encryprion keys. Tnis 
scheme is described in mon: detail below. 

2.0 Simple Key-Minagemt;nt for Internet Protocols (SKIP) 

We sdpuJaLc that each IP based source and desdnarion has a cerrified DiJffic-Hcllrrian public key. 
This public'key is distributr d in the foiro of a cerdncace. The cmificacc can be signed using either 
an RS A or DSA signanirc a;gorithm. How the certificates are managed is described in more detail 
later. 

Tnuscach IP source or desc aadon I has a secret value i.and a public value g**i mod p. Sinrilarly, 
LP node J has a secret vaJue j and a public value g**j mod p. 

Each pair of EP source and desdnanon I and J can acquL-e a shared secret g**ij mod p. Tney can 
acquire this shared secret without actually having lo communicate, as long as -he certificate af 
each IP node is known to all the other E? nodes. Since the public-key is obtained from a 
certificate, one naroral way for ail panics lo discover the relevant public-keys is to distribute these 
ccrcLficates using a direccor' service. 

This computable shared secret is used as the basis for a key-encrypdng-key to provide for IP 
packet based authenucanon and encryprion. Thus wc call g**ij mod p ihc long-term secret, and 
derive from it a key Kij. Ki* is used as the key for a shared-key cryptosystem{SKCS) like D£S or 
RC2. 

Kij is derived from g**ij m-xi p by taking Lhe high order key-size bits of g**ij mod p. Since g**ij 
mjodp is mmimally going U) be 512 bits and for greater security is going to be 102^^ bits or higher, 
we can always derive enoU|;h bits for use as Kij which is a key for a SKCS, SKCS key sizes are 
typically in the range of 40-256 bits. 

An imporaj^t point here is ^hat Kjj is" an implicit pah"- wise shared key. It docs not need' co be sent 
in every packet or negodaud ouc-of-band. Simply by exarruning the source of an IP packet, the 
des-inadon IP node can compute this shared key Kij. Because this key is implici:. and is liscdas a 
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raasxcr key, its length car. ix: made as long as desired, without any additionai prouxol overhead, in 
order to make cryptanalys;;; of Kij arbia^)' difF.cuI-. 

Ws us£ Kij to -ncr>-pt a trajisicnc key, which •a'c call Kp (for packer cev). Kp is ihen used :o 
encTypt/auLhentica:e an IP ]>acke: or coileccon of packers. Tris is done Ln order to UirJc the acoiaJ 
amount of data in the long- :ena key Since we would like to ke«p the long-term key ror a rela- 
avely long period of dme. !:ay one or tNvo years, we don't encrypt the actual IP data JrafSc in key 

^j- ... 

Insiead we o.nly encrypt :ra.7sieni keys in thij long-tcna key, 3.id use the transient keys to encrypt/ 
authendcate IP data araffic. Tnis limits the ajnount of data encrypted in the long-trrTn kev to a rcl- 
advely srnaJi amount even over a long period of dme like, say, one year. 

Tnus the first dme an IP source I, which has a sicrec value i. needs co communicate v^-ith I? dcsti- 
nation J, which has a secret value j, it cocaputcs ihe shared secret g**xj mod p. It can then derive 
rrom this shared secret Lhc iong-tenn key Xij. IP souix:e I then generaias a random key Kp and 
encrypts this key using Kij. It encrypts the reieVani portion of the IP packet in key Kp (which may 
«.._^e_enaxe IP pacJ:et_orJ.usr.thc_payload.fif-che.IP-packet-depending-on thc-next-orotcK - 
LPS? pnotected data pocon). 

The vaiue of the SAID Seld is used by S KI? to indicate the mcde of processing and to idsnafy the 
impUcit interchar.ge key. Tj-picai modes of processing are encrypted, encrypied-authentdcated. 
authendcated. compression etc. 

The modes of operation are idendfied by -j.e upper 6 bits of the SAID field. The meanings of these 
upper 6 bits is specined in section 2.5 beiow on SAID derived processing modes. The low 22 bits 
■of Lhe SAID ncld are zero. 

If the next protocol field is IP, (in other words IPS? is operating in encrypted-cncapsulaced mode) 
the packet looks as follows. It sends the encrypted IP packet, the encrypted key Kv, encapsulated 
:n a clear outer IP Header. " , . 
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In order :o prepare this pacl;ci for cniission on iht outbound side of IP node J, no communicacson 
was necessary wiih EP nods J. 

When IP node J receives this packec, ic also computes the shared secret Kij and caches it for laiet 
use. order to do this, if it didn't already possess I's certificais, ii may have obtained Ais from 
the local diixciory service.) Using Kij it obtains Kp, and using Kp it obtains the CTriginaJ IP packet, 
which it then deiives^ :o the appropriate place which is cither a local iranspon cndcy or another 
ou[bound intxrrface. 

The Message Indicator (MI) is a field that is needed to preserve ihe statelessness of the protocol. 
If a single key is used in orciei to encrypt. oiuUiple pactets, (which is highly desirable since chang- 
ing the key on a per packet basis consiimces loo much overhead) then the packets need to be 
dccryptabie regardless of Ic 3t or out-of-order packets. The message indicator aeld serves this pur- 
pose. 

The actual content of the .VI field is dependent on the choice of SKCS used for Kp and iis opeu^^i- 
ing cnodc. If Kp refers to a ?lcxk cipher (e.g.. DES) opcradng in Qpher-Block- Chaining (C3C) 
mode, ihen uhe MI for the nrst packet encrypted in key Kp is the Inidaltzanon Vector (P/). For 
subsequent packers, the MI is the lasc blocksirc-bits of ciphcrtcxt of the last (in transG?ic order.) 
packec For DES or RC2 <^ s would be last S4 bits of the last packet. For stream ciphers like 
the MI is simply the count c-f byces thac have already been encrypicd in key Kp (and can be 64 biu 
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long aiso). 

If ihc source I? node (I in wis case; decide:; :o change chc pack:^: cncrypcian key Kp, the r^reivin ? 
I? node J can discover chis fict wiihou: havuTj :c pencmn a public-key operation, li uses 
cached value Kij :o decrypr the encryp:e^l parkst key Kp, 2rd this is a sh2xai' key crypLosysiem 
opcradon. Thus, without rw^uinng comraunicadcn bcr^ctn trinsTrurdng and receiving ctjCS, and 
wiihour ncccssiddng che us; of a public-kcy cpcradon, Lhe packet encrp-pdng key caji be changed 
by Lhc truTiSirining side. 

Since 'iic public keys in che certificates are Dri pufciic keys, chc nodes themselves hive no public- 
key signarare aJgoriihcn. This is not a niajor problecn', since signing on a per-packei basis using a 
public- key crypiosysiem is :oo cumbersome in any case. The.in'je^icy cf the pacxcis is deter- 
mined in a pairwise fasicn using a symmcthc cryprosysism. 

2. 1 SKI? for Packet Authendcadon 

Tn order lo achieve authend<:adon in the absence of phvacy, SKIP coa:plLam iraplemcntauons use 
the encrypred packet key K;3 to encryp: a naessage-digesi of ij\c packet, instead of ihc paekci 
- itself. -This-ena7p:ed-digesT-is appcnded-at-'ie cnd of-the-data portion-of-the-PS-P.-As b^^ 
aJg and Kp aJg idendfy the '^vo encrypdon algoriLhns for keys Kij and Kp. MD alg is a 1 byte 
idendfier for the message digest algorithm. 

This mode of opcradon is Lf:dica!j£d by the SAID value which is funher specified L-. Sccdon 2.x. 
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2.2 Incruder in the Middle ,v,r:acks 

Unauthenucatcd DifSe-Hcllman is suscepdblt co an intruder in rhc niiddle anacJc. To overcome 
ihis. auLhendcared Difne- Helimaji schen:es ha^e been proposed, ihzi include a signature opera- 
rlon with the pardes privarc signature keys. 

SKIP is not suscepdble -o intruder in ihc middle types of atuicks. This is because iht Kffie-Hell- 
35 man public parainetcrs arc long- term and ccrdfied, Incruder in the widdlt artacks on DifSe-Hell- 

.-nan assume that che pardes cannot dcterrrune who the public Diffie-Hcllman keys belong 
:o. Ccrdfied Diffie- Hcllman public keys elirmnate 'J^is possibility, wiihout requiring any 
exchange of messages becw :cn che pa'o pardes or incurring the compucadonaJ overhead of large 
exponent cxponendadons (c:.g., RSA signamres). 



2.3 Storage of Cached Key i 



Since the Kij values need :c be cached for efficiency, reasonable safeguards neied lo be caken io 
45 protect ihesc keys. 

One possible way :o do this is to provide a hardware dev-ice to con^^puie, store and perform opera- 
dons using these keys. This device can ensure that there are no interfaces to extract the key from 
the device. 

50 



55 
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2.4 Manual Keying 



As an intaim measure, in ihc absence of ccrtiiczGcn hierarchies, nodes rsay ^vish lo employ 
manually cxchajiged fccyin ; infcnaadon. To handle such cases, the ^aij key Kij can be the key 
ihar is manually sec up, ■ . ' 

Since manual re-kcying is -i slow and awieward pnx.ess. k snil makes scns^i cc use the vi^'o level 
ke>-ing strucrure,-and cnciyp: \hc packets has die same bcncnc as 'before, namely it avoids over- 
exposing ihc pair key which is advantageous to rnaLatain over reiadvelv long periods of umc 
This is paiiicularly mie for high-speed ner^vo^k 1L-J:s.,whcrc h is ea^y.to encrypt large amounts of 
data over a shore period of dmc. 

2.5 Processing Modes and Said values 

The upper 6 bits of the SA.D Seld axe used :o indicate the pnxcsslng naodc. The processing 
modes defined so far are. encrypdon, authendcadon, compression, and packec sequencing (for 
. -?Jaxbarik.procecaon)..Sinc(:_none.of beingon " " 

indicate ihe employment of all the relevant processing modes. 

SAID bits . 

Sxz 22 Bit 23 3ic 24 3it 25 Biz 25 Siz 21 

-r — ^^^^ 

! ^•--""^■ = ^'=*'^«« ' Compxeaaed i SecTuencad I Ravi | Rjvd ] 

' K • 

Bit 22 = 1 if packet is encrypted, Bit 22 = 0 other*'ise 
Bit 23 = 1 if packet is aiithenticatad, Bit 23 = 0 otherwise 
Bit 24 = 1 if packet is compressed bcfon: cncrypdon. Bit 24 = 0 otherwise, 
..Bit 25 = I if packets arc sequenced. Bit 25 = OoL-.erwise 
Bits 26 aj?.<i 27 axe rcser/cd for future use, and shaU be 0 ur.dl specified. 

For example, to indicate iJ:at a packet is encrypted and authe.-idcated. B:ts 22 and 23 shaii be one. 
3.0 SKIP for Mu Ideas t IP 

!o ' ^^^^ '° "^'1^'^°' ^ =cnj.r,cdor, ^vv.^ daUgr^. multicasdng protocols lik^ 

L ^or r?ng) mutucasc (i]. This requ«s key-mar.agerr.e.-.t awareness in the establishment ai^d 
joming process of rauldcast gjvjups. 

In onder to disrribi:tc multicast keying n^ateriaj. the r.odon of a sn:>up owTier needs to exist. When 
sccuxr muiticasong to mulccas: address M is required, a group .-nembership crr^aaon prirrudve ' 
will need to establish the j.touo scrrrc vaJi:e Km and :hc membershia list of addresses that ar^ 
aJloM-ed to cransniit andns.;eivc cncr>ptcd muidcast datagra.T.s to and from group addret 



M. 
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Tr.c group key Km is net - sr^ as a pac'c^t cncr/pcon key, but raihcr as the group Interchange Key 
(IK). 

^ Nodes %;t-ishing to crajismit/r;ceive encrypied cUtagranis co C2u!dcasc address M need la acqwc 
the group DC Km. T-.is is dc ne by sending an encryptcd/auLncndcacfid request to join priOTdve lo 
the group ov^-ncr. If the requesdng nodes zjd±-c^% is par: of the group s membership, uhcn ihc 
^oup o^er send the K Krr. and associated lifcriisc infarmadon in aji encrypted packet, 
using ihc pairuose-secuje protocol described Ln Sccdon 2 above. 

Transmining rodcs to group, address M will randomly generate packet encrypdon keys Kp, and 
encrypt ir^ese keys using Kix The packet strjcrure is similar to the stniccure used for cr.CTyptcd 
15 unicasc IPSP oackccs. excep : for the fact chat the packet kcYS Kp are not encrypted in the pair-sv^se 
keys Kij. but instead are encrypted using the group IK Kai. An example encrypted raulncasi 
packe: is shown below. 

20 . • • . 
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TncTC are r*^o disdnct adva; -tages of this scheme. FL-sc. every member of the rmiidcast group ca.T 
change packet cncTyption t:ys is often as it desires, vvnthoui involving losy-serup cooununicaaons 
overhead involving every niernber of the group. 

Second, since all the packs: encrytpion keys are diiferent. there is no. problem in using sucam- 
ciphcrs'with aulticast. This is because each soiL^ce of encrypted oafSc uses a different kcy-screa.'c 
a/id thus there is no key-sni--aCT reuse probiem. K all merabers of the rniildcasc group used the 
same packet encrypnon ke^' (as e.g sdpulated in -J-.e current dnfc of S02. 10 key-managcmcni). 
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then kcy-sccdoi scrcain dpiicrs cculd not be used wich rculdcasc. 

Kov*' ihc idcndry of the grou p owner is esublishcd and cotnnunicated lo zhe participadng nodes is 
Izfi lo che application layer. Hov^cvcr, this also needs ro be done L-i a secure fashion. oihcrs«r-ise tht 
underlying key- managcme-.t facility can be dcf2:ited. 

4.0 Managexnent of DH ce.-diicatcs 

Since the nodes' public DH values are cocmunicated in the form of orrdQcaics, the sa-oe son of 
muld-dcr ccrtificacion srmcrure that fi be-j-. g deployed for ?EM [5] and also by the European 
PASSWORD project can b<: used. Namely, there can be a Top Level Omifying AuthorityfTLCA.) 
which may wcU be the sam-i the Internet Pclicy Rigiscr^dcn Auchorir>* CIPR.A), Policy Certifying 
Authorines (PCAs) a: the sitcond der and organizational CAs below that. • - 

la addition to the idcndcy c:rdncatcs, which axe what are pan of PEM certificate infi^strucnu;:, 
wc aJso need addidonai autionzadon cerif.catcs, in order to properly track the ownership of IP 
addresses. Since wc would like ic directly use IP addresses in Lhe DH ccrdficaics. we caxinot use 
name subortiinarion principles alone (as e.g used by PEM) in order to determine if a pardcuJar CA 
--has the-authoriry to bind a ])ardcular-IP a^ 

We can sdll use the X.509/1.^EM ccrtif:care formic, since the subject DUunguithj^d Name (DN*) in 
"iie certLicate can be the numeric string rcpresentadon of a list of TP addresses, . - 

Since the nodes only have ]:)H public keys, which have no signarore capability, ihe nodes axe 
•unemsclvcs unable to issue certificates. This zjicans that thcrs is an aJgorithniic Lcrrninadon of a 
certificate path in a leaf nc<:.e, uniike the cerdf*ca:e hierarchy employed in, e.g PEM, where every 
leaf node is potendally a rogue CA. 

The node cer^.cares are issued by crganizadonai CAs 'J.'hich have jurisdicdon over the range of 
LP addresses that are being cenifted. The PCAs will have to perform suitable checks (in line wi^ 
the advertised policy of L-at PCA) to connrm that the organitadon which has jurisdicaon ov-r a 
range of addresses is issucc a cerdncare giving it the auuhoricy to certify the DH values of individ- 
ual nodes with Lhose addresses. This authonty will be delegated in the form of a authorizaoon cer- 
dficate signed by the PCA. For the purposes cf authorizauon, the CA's Disdnguished Name (DN) 
will be bound the range of IP addresses over which it has jurisdicdon. The CA has cither an 
RSA or DS A cerdncaie iss ied by Lhe PCA. 

An authorize don cernficac< will aJso contain infcmiadon about whether uhc CA to whom author- 
icy is being delegated can sib- delegate that authoncy. Tne CA which has deiegatabls authonty 
over^ a range of IP arlcLresse ; can delegate authciiry over pan of the range to a subordinate CA. by 
signing another authorizadon ccnificace using its rwn private key. If the authorirv is non-delcgat- 
able, then Lhe CA carmot delegate aud^ohty for char range of addresses, 

Tne range of IP addresses :re idendiied in the audiorizadon cerdScate in the form of a lis: of IP 
address prefix, length pairs 
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5.0 X.509 Encoding of SK]? DH ceniiicaies 

5. 1 Encoding of DH public values 

The encoding of a DH Public value in an X.509 crrcificate will be in 'iic foirn of an INTEGER. 
Tnc algoriLhm iodcntificr uiU be as def-icd in PKCS #3 [7]. Thus 



-ajidfronPKCS #3, 

75 AI<joric.VciIdenC liter ::- 

aigc^irhm 03JEC7 IDE^MTrriER 

prima: IJJTEGER, ? 

bai;e mxZQZ^, g 

) 

wi'Ji the OBJECT mENTIFTER value being ' 

<ih;<«yAgreeTTi«nc* 03J£CT rD£NTZFISR 

{iso<l) nx«f:\b«i:-bo<ly (2) US i3<0) 

raada:.. (113549) p)tc5(l) 3 i; 

which is also taken from P KCS #3. 



DHPubiicKey Is what gets encapsulaEd as the BIT STRING in SubjeciPublicKcylruo of an 
35 X.509 ccrdficatc in the ob^'ious manner, 

5.2 Encoding of the DiscLn f Jished Kame (DJ^O 

The certificate is allowed o bind multiple P addresses lo a single public value to accomnnodatc 
cases where a single IP nalc has muldplc IP addresses. The SEQUENCE OF consoTLict in a DN 
rradily allows for this. What is needed is an OBJECT DDENTTFIER for an AraibmeTypc specify- 
ing an IP address. This is ccfincd here as. 



50 



ipAddr«35 ATTRIBUTE '•^ITH ATTRlBUTt-SWTXX 

Prir.tableSt ring (3 :ZE :i . . ub-ipArfdreaa ) ) 
::- J Lp3cc-oid 11 — N^^d Co rogiaeer chia xxx 

Tr.« in c^e cert.if ica'ce can cor.cal'a .-nulciole 

of these by iteratLng on the SEQUENCE OF consaruct of the Relative 
Distinguished Name Scqui:ncc. 
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The PrinLabie scring contain:; either the hexari^cimai reprcscniauon or standard dct noudon rrprc-- 
scntadon of am IP address. 

5.3 Enccxiing of an Auihori::anGn Cerdficars 

An authorizadoa ccxrdficate is aiscciated each CA below the PCA jevei. TTic authorizadon 
cerdncaie in effect enddes a CA to bind TP addresses toDH public tcys. 

6.0 Conclusions ' - - , . 

Wc have describcxi a schcmn. Simple Key- Mar.agcuicni for Internee Protocols (SKIP) that is par- 
dcularly well suiccd :o ccnnacdordess dacagram protocols like IP and its replacement candidate 
SEPP. Both the protocol and compuudonal overheads of this schcir.e are rdadveJy low. In-bajid 
signalled keys incur the length overhead of the block siic of a shared-key cipher. Also, serdng and 
cha-n^ng packet cncrypdng keys involves only a shared-key ciphex-cpexarian. Yet the scheme has 
the scaJabiliry and robustnc:;s of a public- key cerdncate based infrasirucnirc- 

A major advantage of this s cheme is that establishing and changing packet encrypdng keys 
requires "no coiTirnunTcation~berw^^^^ " ~ " 

pseudo-session state between the two sides is required. 

In 3iany ways the key-nian2;gemcnt scherrc here has scr^crural similarides wiLh the scheme used 
by ?HM (1], Boch use the ccinccpcof an inccr-change key (in our case thai is the pair keys Kij) and 
data encrypdng keys (the pcckct cncrypuon iceys Kp). By using the in:plicic shared secret prop- 
erty of long-ccrra DH pubii<: values, and creaung the resulting keys as keys for a SKCS. we have 
reduced the protocol ovcrh? ad substandaJly as compared to the overhead of PEM when used in 
conjuncdon with an asyTnuieaic key- mai^agcmenc system. 

We have also described hov/ this scheme rriay be used in conjuncdon with datagram multicast 
protocols, allowing a single encrypted datagram x> be muldcast to ail the receiving nodes. 
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Claims . 

1. A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first 
computer network to a second host computer on a second computer network, the f i rst and second computer networks 
Including, respectively, first and second bridge computers, each of said first and second host computers and first 
and second bridge computers including a processor and a memory for storing instructions for execution by the 
processor, each of said first and second bridge computers further including memory storing at least one predeter- 
mined encryption/decryption mechanism and information identifying a predetermined plurality of host computers as 
hosts requiring security for packets transmitted between them, the method being carried out by means of the instruc- 
tions stored in said respective memories and including the steps of: 

(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a 
portion of the data packet including information representing an internetwork address of the first host computer 
and an internetwork address of the second host computer; 

(2) in the first bridge computer, intercepting the first data packet and determining whether the first and second 
host computers are among the predetermined plurality of host computers for which security is required, and if 
not, proceeding to step 5, and if so, proceeding to step 3; 

(3) encrypting the first data packet in the first bridge computer; 

(4) in the first bridge computer, generating and appending to the first data packet an enapsulation header, 
including: 

(a) key management information identifying the predetermined encryption method, and 

(b) a new address header representing the source and destination for the data packet, 
thereby generating a modified data packet; 

(5) transmitting the data packet from the first bridge computer via the internetwork to the second computer 
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network; 

(6) intercepting the data packet at the second bridge computer; 

(7) in the second bridge computer, reading the encapsulation header and determining therefrom whether the 
data packet was encrypted, and if not, proceeding to step 10, and if so. proceeding to step 8; 

(8) in the second bridge computer, determining which encryption mechanism was used to encrypt the first data 
packet; . ^ ... . 

(9) decrypting the first data packet by the second bridge computer: 

(10) transmitting the first data packet from the second bridge computer to the second host computer; and 

(11) receiving the unencrypted data packet at the second host computer 

The method of claim 1. wherein the new address header for the modified data packet includes the internetwork 
broadcast addresses of the first and second computer networks. 

The method of claim 2. wherein the new address header for the modified data packet includes an identifier of the 
second bridgecomputer _ _ '_ _ _ _^ 

The method of claim 1 , wherein the new address header of the modified data packet includes the address of the 
second host computer 

The method of claim 4, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer 

A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first 
computer network to a second host computer on a second computer network, including; 

a first bridge computer coupled to the first computer network for intercepting data packets transmitted from 
said first computer network, the first bridge computer including a first processor and a first memory storing instruc- 
tions for executing encryption of data packets according to a predetermined encryption/decryption mechanism; 

a second bridge computer coupled to the second computer network for intercepting data packets transmitted 
to said second computer network, the second bridge computer including a second processor and a second memory 
storing instructions for-executing decryption of the data packets; 

said first host computer including a third processor and a third memory including instructions for transmitting 
a first said data packet from said first host to said second host; 

a table stored in said first n:iemory including a correlation of at least one of the first host computer and the first 
network with one of the second host computer and the second network, respectively; 

instructions stored in said first memory for intercepting said first data packet before departure from said first 
network, determining whether said correlation is present in said table, and if so, then executing encryption of said 
first data packet according to said predetermined encryption/decryption mechanism, and transmitting the first data 
packet on to the second host computer; 

instructions stored in said second memory for intercepting said first data packet upon arrival at said second 
network, determining whether said correlation is present in said table, and if so, then executing decryption of said 
first data packet according to said predetermined encryption/ decryption mechanism, and transmitting the first data 
packet to the second host computer 

The method of claim 6, wherein the new address header for the modified data packet includes the internetwork 
broadcast addresses of the first and second computer networks. 

The method of claim 7, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer 

The method of claim 6. wherein the new address header of the modified data packet includes the address of the 
second host computer 
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10. The method of claim 9, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer. 

11. A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first 
computer network to a second host computer on a second computer network, the first and second computer net- 
works, each of said first and second host computers including a processor and a memory for storing instructions 
for execution by the processor, each said memory storing at least one predetermined encryption/decryption mech- 
anism and a source/ destination table identifying a predetermined plurality of sources and destinations requiring 
security for packets transmitted between them, the method being carried out by means of the instrucdons stored in 
said respective memories and including the steps of: 

(1) generating, by the first host computer a first data packet for transmission to the second host computer, a 
portion of the data packet including information representing an internetwork address of a source of the packet 
and an internetwork address of a destination of the packet; 

(2) in the first host computer, determining whether the source and destination of the first data packet are among 
the predetermined plurality of sources and destinations identified in said source/destination table for which 
security is required, and if not, proceeding to step 5, and if so. proceeding to step 3; 

(3) encrypting the* first data packet in the first host computer; 

(4) in the first host computer, generating and appending to the first data packet an enapsulation header, includ- 
ing: 

(a) key management information identifying the predetermined encryption method, and 

(b) a new address header identifying the source and destination for the data packet, 
thereby generating a modified data packet; 

(5) transmitting the data packet from the first host computer via the internetwork to the second computer network; 

(6) in the second host computer, reading the encapsulation header, and determining therefrom whether the 
data packet was encrypted, and if not, ending the method, and if so, proceeding to step 7; 

(7) in the second host computer, determining which encryption mechanism was used to encrypt the first data 
packet; and 

(8) decrypting the first data packet by the second host computer. . 

12. The method of claim 1 1 , wherein the new address header for the modified data packet includes internetwork broad- 
cast addresses of the first and second computer networks. 

13. The method of claim 11, wherein the source/destination table includes data identifying internetwork addresses of 
the first and second host computers. 

14. A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first 
computer network and having a first processor and a first memory, via an internetwork to a second host computer 
on a second computer network and having a second processor and a second memory, the system including: 

security data stored said first and memories indicating that data packets meeting at least one predetermined 
criterion are to be encrypted; 

a predetermined encryption/decryption mechanism stored in said first and second memories; 
a decryption key stored in said second memory; 

instructions stored in said first memory for determining whether to encrypt data packets, by determining 
whether said predetermined criterion is met by said data packet; 

instructions stored in said first memory for executing encryption according to said predetermined encryp- 
tion/decryption mechanism of at least a first said data packet, when said criterion is met, and for appending an 
encapsulation header to said first data packet and transmitting said first data packet to said second host, said 



21 



EP O 702 477 A2 



encapsulation header including at least an unencrypted destination address for said first data packet; 

instructions stored in said second memory for receiving said first data packet, determining whether it has been 
encrypted by reference to said security data, and if so then determining which encryption/decryption mechanism 
was used for encryption, and decrypting said data packet by use of said decryption key. 

15. The system of claim 14, wherein: 

said security data comprises correlation data stored in each of said first and second memories identifying at 
least one of said first host computer and said first network correlated with at least one of said second host computer 
and said second network; 

the system further including instructions stored in said first memory for determining whether to encrypt data 
packets by inspecting for a match between source and destination addresses of said data packets with said corre- 
lation data. 
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(54) System for signatureless transmission and reception of data packets between computer 
networks 



(57) A system for automatically encrypting and de- 
crypting data packet sent from a source host to a desti- 
nation host across a public internetwork. A tunnelling 
bridge (TB) is positioned at each network (N), and inter- 
cepts all packets transmitted to or from its associated 
network. The tunnelling bridge includes tables indicated 
pairs of hosts or pairs of networks between which pack- 
ets should be encrypted. When a packet Is transmitted 
from a first host, the tunnelling bridge of that host's net- 
work intercepts the packet, and determines from its 
header information whether packets from that host that 
are directed to the specified destination host should be 
encrypted; or. alternatively, whether packets from the 
source host's network that are directed to the destina- 
tion host's network should be encrypted. If so, the pack- 
et is encrypted, and transmitted to the destination net- 
work along with an encapsulation header indicating 
source and destination information: either source and 
destination host addresses, or the broadcast addresses 
of the source and destination networks (In the latter 
case, concealing by encryption the hosts' respective ad- 
dresses). An identifier of the source network's tunnelling 
bridge may also be included in the encapsulation head- 
er. At the destination network, the associated tunnelling 
bridge Intercepts the packet, inspects the encapsulation 
header, from an internal table determines whether the 
packet was encrypted, and from either the source (host 
or network) address or the tunnelling bridge identifier 
determines whether and how the packet was encrypted. 



If the packet was encrypted, it is now decrypted using a 
key stored in the destination tunnelling bridge's memory, 
and is sent on to the destination host. The tunnelling 
bridge identifier is used particularly in an embodiment 
where a given network has more than one tunnelling 
bridge, and hence multiple possible encryption/decryp- 
tion schemes and keys. In an alternative embodiment, 
the automatic encryption and decryption may be carried 
out by the source and destination hosts themselves, 
without the use of additional tunnelling bridges, in which 
case the encapsulation header includes the source and 
destination host addresses. 
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